In many video streaming techniques files can be streamed in chunks over a network protocol, for example using the video streaming technique referred to as HTTP Adaptive Streaming (HAS).
A chunk may be understood as a fragment (stored as part of a larger file) or a segment (stored as separate files), which may be played-out by a client device. Chunks can have any duration, but are usually either 2 (e.g., Microsoft Smooth Streaming) or 10 (e.g., Apple HTTP Live Streaming) seconds each.
The content files or content items, in particular media files such as videos, may be available in multiple quality representations, each representation comprising a number of time-sequential chunks.
A characteristic of a chunk may be the quality of the representation it belongs to. For example, a quality of the representation of a video file may have a (play out or rendering) bit rate of 2 Mb/s or 4 Mb/s. When different chunks, belonging to representations with different qualities, are available in a content delivery network (CDN), a client device (e.g. a device comprising an adaptive streaming client) connected to that network, arranged to play out said chunk, may seamlessly adapt the quality of its play-out (for example of the video) by retrieving chunks belonging to representations with different qualities, based on current network and device conditions.
Alternatively, the client device may adjust the quality of its play-out during play-out of a chunk by stopping the play-out of the chunk and seamlessly starting play-out of a chunk belong to representation with a higher quality. This may for example be achieved using a protocol such as Apple HLS.
The client device may request a manifest file (also referred to as a Media Presentation Description (MPD)), which comprises information about chunks forming a content file (such as a video). This information may comprise chunk identifiers identifying specific chunks, the network locations of said chunks (for example in the form of a domain name, an URL or an IP address), the quality of the representation to which each chunk belongs, and/or a time-sequence number.
Multiple representations of a content file (e.g. a video) may thus be available in one or more networks in the form of chunks belonging to representations with different qualities. These chunks may be located (distributed) at different network locations or network elements (e.g. residing on content servers, delivery server and/or caches in the one or more networks).
It is furthermore feasible that more than one copy of a representation (set of chunks) or of a part of a representation (e.g. only certain chunks) may exist in these one or more networks. This may be due to for instance load balancing algorithms in a network (e.g. more popular content is requested more frequently and hence may be stored at more locations than unpopular content), or when for example different networks relate to different (access) technologies or are owned and/or managed by different parties.
Usually the network comprises network elements such as delivery servers, routers and/or caches. On a delivery server one or more chunks may be stored, while on a cache a copy of said chunks may be stored.
When a client device transmits a request to a delivery server for a specific chunk, the cache may intercept the request and check whether the requested chunk is locally stored. If the requested chunk is locally stored, the chunk is served, provided or delivered directly by the cache. If not, the request is forwarded by the cache to the next network element on the path towards the delivery server. Such a type of cache, also referred to as a transparent cache, is an example of a transparent network element. A transparent cache may be described as a computer system, or software within a computer system, that determines if a requested page or file (e.g. a chunk) has already been stored in memory or on its hard disk. If it has not, the request is sent upstream to its normal destination. More generally speaking, a transparent network element sits between the client and server and is invisible to either side. For reaching a transparent network element no special HTML code or DNS redirection (from a content source) is required. The next network element in the path may for example be another transparent network element (e.g. transparent cache) or may be the delivery server (sometimes also referred to as origin server) itself. A delivery server (or origin server) is an example of a non-transparent network element, if it is specifically addressed in the request made by the client. Another example may be a request routing function being hosted on a computer system. A transmission path between the client device and the delivery server (e.g. the route followed by a request from a client and/or by the response) may be called a delivery path. A delivery path may comprise overlapping caches with other delivery paths. Moreover, multiple delivery paths may exist from the client device towards the same server, e.g. through different access networks.
Rate adaption algorithms, used by client devices known in the art, may use an estimation of the available end-to-end bandwidth between the client and a delivery server to decide which chunks of which quality representation to download. Such estimation may be based on a measured download time of chunks and/or the state of a client-side buffer, and thus may provide an estimation of the bandwidth perceived by the client device during content retrieval.
These adaption algorithms may work well when all chunks are stored on or originate from a single location or at least on/from multiple locations with similar bandwidth conditions. In practice, multiple delivery paths to a client device, whereby these paths for instance originate from different locations will usually also lead to differences in perceived bandwidth by the client device. This may be caused by different (and varying) network circumstances on these delivery paths. For example the usage of a part of the network may vary, as well as the length of one path over the other, the processing power at the network elements in the delivery path, including the delivery servers and/or caches and so on. Moreover, when caches on the path towards a delivery server host a subset of available chunks, and where multiple delivery servers may host chunks with the same content, a single point of origin can no longer be assumed.
Thus, an estimation of the available bandwidth to a single destination may no longer be accurate for the rate adaptation algorithm.
In US2012/0265856 a method and a system for data streaming in a computer network is disclosed. In such a network a cache server may be configured to offer bit rate hint data to the client, which enables the client to execute decisions about its bit rate requests. The cache server may be configured to transmit information about current load conditions for a cache server, along with information related to upstream bandwidth parameters.
According, to US2012/0265856 a client may request a high-quality bit rate and when a cache server receives this request, it analyzes the current criteria affecting the file transfer. Upstream criteria are generally not visible to the client without use of the rate hint data. These criteria can be inclusive of any suitable network characteristic that can affect a bit rate decision such as upstream hits (i.e., requests for particular content), current cache status, upstream bandwidth, load conditions, etc.
However, when multiple delivery servers and/or caches host the same chunks and/or multiple delivery paths exist between a client device and a delivery server, the method and system described in US2012/0265856 may not provide sufficient information for the client device to select a chunk with the optimum quality representation.
For example, when the client device may retrieve chunks via two different delivery paths, only the caches in the default delivery path, which is actively used by the client device to request chunks from a delivery server, may intercept this communication and may thus provide information about network conditions upstream (or downstream) of such cache. Caches that are in the other delivery path, which is not used by the client, will not be able to intercept any communication and will therefore not provide any information, because they are unaware of the needs of the client device.
These situations may for example occur when a client device such as a smartphone is connected through a first access network (such as WLAN) to a (content delivery) network. The same smartphone may also be able (have the capabilities) to connect to and retrieve representations of the same content via a second access network (such as LTE). Since the client device is however not using this second delivery path for content retrieval, the network elements in this potential second path do not provide any information regarding the network circumstances in this second path. Since the first delivery path may be the sub-optimal available path with respect to certain content, the known prior art may not always optimally serve the client's needs.